Why We Need to Track Breakage？UX 為何需要追蹤建議“斷裂”

"追蹤建議斷裂，就是找出建議在哪個環節失效了"。

從"學到了什麼"到"做了什麼"

傳統研究常關注"我們學到了什麼"，但更重要的問題是"我們做了什麼"。

如果不追蹤斷裂，團隊就不知道：

• 哪些建議真的被執行了；

• 哪些建議只做了一部分；

• 哪些建議被完全忽略了。

為何必須追蹤斷裂

1. 找出薄弱環節

追蹤斷裂能幫我們找到問題出在哪：

• 是資料沒問題，但彙報時說得不清楚？

• 是洞察準確，但設計團隊理解錯了？

• 是建議合理，但因為領導不支援就被擱置了？

2. 不追蹤斷裂的後果

如果不追蹤這些失效的地方，團隊永遠不知道問題在哪，也就無法提高研究的影響力。一旦開始追蹤，就能看清楚從資料到最終產品，整條鏈是否暢通。

建議背後的"證據鏈"

每條研究建議都是這樣一步步形成的：資料 → 研究發現 → 洞察 → 建議如果建議沒被採用，整條鏈就斷了。就算研究做得再好、發現再有道理，建議沒做到產品裡，研究就白費了。

圖示解析：研究價值鏈（The Value Chain of Research）

圖中展示了研究如何一步步產生價值，從左到右包括：

1. Data（資料）

例子：HelpZone 首頁的點選資料。

2. Finding（發現）

資料分析的結果：

"只有 0.03% 的使用者點選了'精選文章'區域。"

3. Insight（洞察）

這個資料說明瞭什麼：

使用者根本不看這個區域，覺得它沒什麼用，白白浪費了頁面空間。

4. Recommendation（建議）

根據洞察提出改進方案：刪掉"精選文章"區域，換成使用者真正需要的自助服務功能。

目的與意義

圖中用不同顏色標出每一步，說明一個重點：研究越深入，價值越高，最有價值的是能直接執行的建議。

這條鏈中任何一環出問題，最後的建議都會失效。

UX 設計師如何追蹤斷裂

下面這些方法，可以幫助 UX 設計師找到建議在哪裡"卡住了"。

1 關注"建議是否真的做了"

• 不要只問"我們發現了什麼問題"，更要問"我們做了什麼改變"。

• 設計師要追蹤：建議有沒有被採用、有沒有做到產品裡、有沒有真正幫到使用者。

• 可以用"建議採納率"這樣的指標來衡量

2 識別問題的早期訊號這些情況說明建議可能要"夭折"了

• 團隊說"再研究一次"，但沒說清楚新研究能改變什麼決定。

• 彙報時，最重要的建議被輕描淡寫地帶過，因為"不太方便說"。

• 設計師繞開建議，用現成的元件庫方案湊合，雖然簡單但解決不了根本問題。

• 寫了一堆檔案，但沒有具體任務、負責人、上線計劃。

• 管理層只會說"我們在做研究"，說不出"我們因為研究做了什麼改變"。

• 研究人員不再被邀請開會；產品上線後，才從使用者投訴中發現問題還在。

3 找出最容易出問題的環節不同公司問題不同

有的在排優先順序時丟了建議，有的在設計時理解錯了，有的在開發時為了趕進度砍掉了功能。所以要在每個環節（研究 → 洞察 → 建議 → 產品上線）都設定追蹤點，記錄負責人、狀態、優先順序、交付時間。

4 明確"誰負責落地"和"進展到哪了"重點不是追究責任，而是把"建議落地"當成重要目標來管理

每條建議都應該標明：誰負責、現在什麼狀態（待辦、設計中、開發中、已上線）、優先順序多高、用什麼指標衡量效果（比如轉化率提升多少）。

UX 設計師如何修復斷裂

把洞察變成可執行的建議

• 建議是整個研究中最有價值的部分。

• 研究完成後，要給出具體的行動方案：改什麼、誰來做、什麼時候做、怎麼衡量效果。

• 避免模糊的說法，比如"我們可以考慮..."。要說清楚：做什麼（what）、誰做（who）、什麼時候做（when）、怎麼衡量（how）。

把建議加入產品計劃

• 建議常因為優先順序衝突、資源不夠、團隊各管各的而被擱置

• 主動跟產品經理、開發團隊、業務負責人溝通，把建議變成具體任務，加入工作計劃。

• 說清楚建議能解決什麼使用者問題、影響多少使用者、預計提升哪些資料，這樣更容易獲得支援和資源。

上線後繼續跟蹤效果

• 功能上線不等於問題解決。有時候改了一部分，但關鍵問題沒改，使用者流失率還是沒改善。

• 上線後要監測資料（流失率、轉化率、使用者滿意度等），看看效果是否達到預期。如果沒達到，就要重新研究和調整。

• 可以設定目標：比如"流失率從 X% 降到 Y%"，如果沒達到，就啟動回顧和改進。

找出組織裡的阻礙並想辦法解決

• 建議落不了地，通常不是某個人的問題，而是公司運作方式的問題：優先順序總在變、團隊各幹各的、不知道誰負責、趕進度壓力大等。

• 設計師應該主動推動：
  • 找到支援建議落地的高層領導
  • 組建跨部門團隊（設計、產品、開發、運營）共同推進
  • 在規劃會上持續追蹤建議進展，避免被"一直待辦、一直不做"。

• 如果有資源但建議還是不落地，要用資料向管理層反映，推動改變。

把採納率作為考核指標

給 UX 設計師的實用建議

• 研究報告裡不只寫"發現了什麼問題"，還要給出具體建議，並標明負責人、優先順序、衡量指標。

• 在產品規劃會上，把建議變成待辦任務，確保進入設計和開發流程。

• 功能上線後一個月，回顧效果：使用者行為有沒有改善？沒有的話，覆盤找原因。

• 建一個"建議追蹤表"：記錄建議內容、負責人、狀態、優先順序、上線日期、效果資料。

• 每季度回顧：哪些建議執行了、哪些被忽略了、為什麼，找出流程瓶頸。

• 在公司內推廣這個理念：研究的價值不只是發現問題，更在於推動改變。

用“採納率”衡量 UX 價值 "RAS"讓建議可見、可追蹤

Recommendation Adoption Score 這是一個判斷建議是否被採納、是否完整落地、價值是否傳達到終端使用者的管理工具。它能幫助我們看到建議在哪個環節出現了 breakage（斷裂）。

RAS = 全部建議的平均得分，類似 OKR 。

RAS =（採納分 × 完整度 × 影響度）

三個維度，每個都是 0～1 分，最終 RAS 也會是 0～1 之間的小數（越接近 1 越好）。

公式：

RAS = (Adoption × 0.5) + (Fidelity × 0.3) + (Impact × 0.2)

50%權重：Adoption 採納是最關鍵（做沒做）

30%權重：Fidelity 完整度影響體驗

20%權重：Impact 影響度最難立刻測但必須考慮

採納分 Adoption（有沒有被做？）

0 = 未採納（完全沒做）

0.25 = 被弱化（有做一點，但本質沒解決）

0.5 = 部分採納（做了部分關鍵點，但重要部分沒做）

0.75 = 大部分採納（關鍵建議都做了但打了折扣）

1.0 = 完全採納（按建議 100% 做到）

完整度 Fidelity（實現質量如何？）

0 = 做了，但偏離使用者問題

0.5 = UI/互動實現不符合方案，效果打折

1.0 = 按洞察 & 設計原意完整實現

影響度 Impact（有沒有改變使用者行為？）

0 = 未上線或上線但沒有影響

0.5 = 有改善趨勢但未驗證

1.0 = 資料明確改善

結果：

0.6 – 0.75 = 正常（健康但有提升空間）

0.75 – 0.9 = 高（優秀團隊）

0.9 – 1.0 = 極高（頂級成熟度）